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F or many software applications, communicating 
withtheuserin asinglelanguage(usuallyEnglish) is 
sufficient. However, some applications, such as 
those supporting customers in an urban banking envi¬ 
ronment, must communicate with users from diverse 
language backgrounds. These applications must be 
designed to support dynamically changing languages at 
the user interface. For example, Figure 1 illustrates a sin¬ 
gle test window that has been opened in both English 
and French as determined by the user’s language prefer¬ 
ence selection. 

I refer to thisconcept of dynamic language selection as 
multiple language support (MLS), to differentiate it from 
the more common national language support (NLS) 
which assumes the use of only a single language. This 
article describes parts of the multiple language frame¬ 
work that our team at the Toronto-Dominion Bank is 
developing using Digitalks Visual Smalltalk. 

THE LANGUAGEMANAGER CLASS 

Central to the M LS framework is a subclass of NationalLang- 
uageSupport called LanguageManager. A singleton instance 
of LanguageManager isplugged into the existing global vari¬ 
able NationalLanguage at application start up time. 

In addition to the responsibilities it inherits, Language- 
Manager adds the capability to manage language files. 
Each language file contains the information required to 
translate and format all on-screen text within the appli¬ 
cation into a particular language. We can incrementally 
add new languages simply by distributing new language 
files without redeveloping the application. 

The LanguageManager singleton manages these language 
files (with help from ObjectFiler) via two public methods: 

• LanguageManager»getSupportedLanguages. Answers a 
collection of language names that are currently sup¬ 
ported by the application. During application startup, 
the LanguageManager singleton scans the directory for 
all language files (e.g., *.lng) to build this collection of 
language names. 

• LanguageManager»setLanguage: aLanguageName Sets 
the current language to the one identified byaLanguage 
Name. Thismethod loads the contents of the appropri¬ 
ate language fi le from disk. This message is typical ly 
received from a user preferences selection tool. 

Each languagefilecontains a dictionary to translate wid¬ 


get labels, menu labels, and other strings. It also contains 
various data formatting information such as the decimal 
separator character and date formats. Once loaded from 
file, this information is maintained in instance variables 
within the LanguageManager singleton. In particular, the 
instance variable stringDictionary is populated with the 
dictionary of translated strings. 

The keys for stri ngDi cti on ary are language-neutral 
string abbreviations. In the case of widgets and menu 
items, the label text that was assigned to the widget or 
menu item at GUI, design time is used as the key (e.g„ 
'CloseButn'). I n the case of other displayable stri ngs, such 
as those displayed in message boxes, the key is a lan¬ 
guage-neutral abbreviation such as'ErrMsgComm073'. 

Typically, the language dictionary for each language is 
created and maintained in a spreadsheet. It is read into 
the development image and saved into the language 
object file using additional LanguageManager methods. 

Some points regarding performance are in order here. 
If the stri ngDictionary gets too big, the dictionary lookup 
times may become unacceptably slow. Also, the use of 
Strings as dictionary keys is less efficient than using 
Symbols as keys to an I dentityDictionary. 

One sol ution to the fi rst problem i s to factor the d ictio- 
nary into smaller dictionaries. Our production applica¬ 
tion uses three dictionaries within the LanguageManager 
singleton, one each for widget labels, menu labels, and 
general strings. Other methods of factoring are possible, 
however for simplicity, the framework described here has 
only one language dictionary. 

With respect to the second issue, the choice of Strings 
as keys in stringDictionary was motivated by the fact that 
the GUI environment and tools assume the use of Strings 
for the names and labels of widgets and menus. A design 
using Symbols would require hacking the GUI environ¬ 
ment and tools. Such a design would also have to avoid 
using the String»asSymbol method, which performs its 
own (larger and longer) string-keyed dictionary look up. 
The String keys have proved to be fast enough in our ap¬ 
plication, though this remains an area for potential per¬ 
formance improvement. 

TRANSLATING STRINGS 

The primary collaborator with LanguageManager is the 
String class itself. Strings respond to the asMLSString mes- 
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sage and simply delegate the translation work to the 
LanguageManager singleton as follows: 

String»asM LSStri ng 

"Answers my translation in the current language." 

''NationalLanguage translateString: self 

which is handled by LanguageManager as: 

LanguageManager»translateString: keyString 
"Answer the translation of the string keyString." 

''self stringDictionary at: keyString ifAbsent: [ 
keyString ] 

Notice that the original key string is returned if a transla¬ 
tion string could not be found.Thisallows the application 
to work even if some or all translations are missing from 
the language file. This comes in handy during develop- 
mentwhen theGUI and language files arein astateofflux. 

TRANSLATING WIDGETS 

The translation of widgets and menu labels takes place 
during the opening of a window. We added the following 
method to theTopPane class: 

TopPane»translateWindow 

'Tell myself, all my widgets, and my menu bar to 
translate themselves." 

self translate. 


self allChildrenDo: [ :each | each translate ]. 
self menuWindow translate. 

which sends the translate message first to itself, then to all 
of the widgets contained on the window, and then to the 
window’s menu bar. 

TheTopPane»translateWindow message is sent after the 
widgets and menus have been created as objects but be¬ 
fore they have been made visible. The question of which 
object sends this message depends on which GUI builder 
is being used. Under WindowBuilder, a good place to send 
this message is in the prelnitWindow method of the View- 
Manager subclasses. Under PARTS, a subclass of PARTS- 
WindowPart can be created to override the open method so 
that the window translates itself before opening: 

MLSPARTSWindowPart»open 
"Translate myself before opening." 

self translateWindow. 

''super open 

In ourMLSframework, all objects respond to thetranslate 
message. The default method (defined in Object) does 
nothing. All widgets and menus with a displayable label 
override this defau It method to specifi cal ly transl ate thei r 
label text. For widgets and windows this is done in the 
ControlPane and TopPane classes, respectively, and is the 
same for both classes: 
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Figure 1. Illustration of a single test window opened in both English and 
French. Notice that even the menu accelerator keys can sometimes be 
different. 


TopPane»translate 

ControlPane»translate 

"Translate my label according to the current language." 

self label: (self label asMLSString). 

In this method, the widget retrieves its existing language- 
neutral label string and tells it to translate itself. The 
resulting translated string is then assigned back to the 
label. To stop nil labels from breaking the system we also 
added an UndefinedObject»asM LSStri ng method which 
simply answers nil. 

TRANSLATING MENUS 

Translating menu labels is a little more complex because 
of the need to register menu selection accelerator keys 
(e.g„- Ctrl+S), which may be different for each language. 

Recall thattheTopPane»translateWindow method sends 
the translate message to the menu bar. In a non-PARTS 
application, the menu bar is an instance of MenuWindow 
and it simply passes the message on to its component 
menus: 

MenuWindow»translate 

"Tell each of my menus to translate itself." 

self menus do: [ :each | each translate ]. 

The Menu»translate method first translates its own title 
(e.g.. File, Edit, etc.) and then cycles through each of its 
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menu items telling each menu item to translate itself 
before setti ng the accelerator key for the menu item: 

Menu»translate 

"Translate my title, then translate my menu items." 

self title: ( self title asMLSString ). 
self translatel terns. 

Menu»translatel terns 

"Tell each menultem to translate itself and then set its 
accelerator key." 

self items do: [ :each | 
each translate, 
self setAccelKeyOf 

From here, theMenultem»translate method translates its 
own label and then tellsanysubmenu (which would bean 
instance of M enu) to translate itself. 

Menul tem»translate 

"Translate my label text and if I have a submenu, 
translate it." 

self label: (self label asMLSString ). 
self submenu translate. 

Note that because the default implementation of the 
translate method in Object does nothing, this method will 
work correctly even if the submenu is nil (i.e., there is no 
submenu). 

Finally, the Menu»setAccelKeyOf: method is where 
things get a little complicated and algorithmic. This meth¬ 
od extracts the accelerator substring from the menu item 
label (e.g., 'Ctrl+S') and then parses the components of this 
substring to convert them into a key code and bit flags. 
These are i n turn i nserted i nto an array of accelerators that 
ismaintained bytheMenu instance.Thiscodeisasfollows: 

Menu»setAccelKeyOf: mltem 

| Ibl tablndx accelString itemlndx bits bitsString key 
keyString | 

( Ibl := mltem label) isNil ifTrue: [ '"self ]. 

(tablndx := Ibl indexOf: Tab) >0 ifFalse: [ "'self ]. 
accelString : = ReadStream on: ( Ibl copyFrom: (tablndx 
+ 1) to: Ibl size ). 

accelString isEmpty ifTrue: [ '"self ]. 
itemlndx :=self items indexOf: mltem ifAbsent: [ '"self ]. 
bitsString : = accelString upTo: $+. 
keyString : = accelString upTo: $+. 
keyString first isDigit 
ifTrue: [ 
key : = 0. 

1 to: keyString size do: [:i | 

key := key* 10 +( keyString at: i) digitValue ]. 
bits : = AfVirtualkey ] 
ifFalse: [ 

key := keyString first, 
bits : = AfChar ]. 
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( bitsString includes: $C) ifTrue: [ bits : = bits | 
AfControl ]. 

( bitsString includes: $A ) ifTrue: [ bits := bits | AfAlt ]. 
( bitsString includes: $S ) ifTrue: [ bits := bits | AfShift ]. 
accel at: itemlndxput: (self accelArray: key accelBits: bits). 


Although all oftheMenu and Menultem methods described 
apply to both PARTS and non-PARTS development, the 
structu re of the men u bar i s si i ghtl y d i fferent u nder P A RTS. 
PARTS keeps the menu titles separate from the actual 
menus, and the Menu instances are not attached to the 
PARTSMenuBar (a subclass of MenuWindow) instance until 
immediately before the window is opened. As a result, 
PARTSMenuBar requires a different translate method: 

PARTSMen u Bar»translate 

'Tell each menu title and Menu to translate itself." 

self children do: [ :each | each translate ]. 
self partApplication componentDictionary 
do: [ :each | 

each isPARTSMenuPart 

ifTrue: [ each menuObject translatelterns ] ]. 

This method fi rst translates the menu titles (accessed via 
self children). It then locates each instance of Menu in the 
PARTS application controlling the window and tells each 
of them to translate their menu items. 

Incidentally, don’t use PARTSMenuBar»translate as an 
example of good programming practice. In a production 
application, we should add methods to both PARTS- 
Application and PARTSMenuPart to reduce the coupling in 
the PARTSMenuBar»translate method. Currently, this 
method must know that the PARTSApplication has a compo¬ 
nentDictionary that contains instances of PARTSMenuPart, 
which in turn holds on to instances of Menu. I cheated a bit 
hereto reduce the amount of code required for this article. 

TRANSLATING MESSAGE BOX STRINGS 

Because any string can be translated, we created a new 
message box that accepts language-neutral abbreviation 
strings instead of raw text. These are then translated into 
the current user language. Therefore, instead of coding 
the following: 


MessageBox warning: This action will destroy the 
known universe.'. 

we would code: 

MLSMsgBox warning: 'WarnUniverseByeBye' 

which would be translated via String»asMLSString before 
the message box was displayed. 

Unfortunately, it is not sufficient to simply create 
MLSMsgBox as a subclass of MessageBox because that class 
relies on native OS message boxes, which use their 
own text for the 'Yes’, 'No', 'OK' and 'Cancel' buttons We 
built MLSMsgBox (and other utility windows such as 
MLSPrompter) from scratch. 

OTHER ISSUES 

The format of numbers displayed as on-screen text or 
in entry fields varies from language to language (e.g., 
$1,000.00 is displayed in some languages as 1.000,00$). 
To handle this, we have added methods such as 
Number»asM LSStri ng which formats the number with the 
appropriate "thousands" and decimal separators. 

For Help files, we maintain a separate Help file for each 
supported language. When a new language is selected the 
LanguageManager singleton renames the Help files so that 
the one associated with the newly selected language will 
be used by the Help system. 

Finally, I have certainly not exhausted the issues 
surrounding full MLS support in this brief article. The 
framework described does not translate the text on any 
window that is already open. This would involve tagging 
all menu components with a name and rebuilding the 
menu accelerator key tables on the fly. I also did not ad¬ 
dress the formidable challenge of supporting text input 
in multiple languages, which touches on issues as 
diverse as physical keyboards and database storage. 
These framework extensions are left as an exercise for 
the reader. §8 


William Hollings is a Smalltalk architect and consultant inToronto. 
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